[Mip6] Summary of Justification for Alternative Authentication Option

Gopal Dommety <gdommety@cisco.com> Thu, 23 September 2004 22:21 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29454 for <mip6-web-archive@ietf.org>; Thu, 23 Sep 2004 18:21:16 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAc4V-0003dd-Rd for mip6-web-archive@ietf.org; Thu, 23 Sep 2004 18:28:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAbiQ-0008Dm-2q; Thu, 23 Sep 2004 18:05:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAbYy-0003eu-Jh for mip6@megatron.ietf.org; Thu, 23 Sep 2004 17:55:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26923 for <mip6@ietf.org>; Thu, 23 Sep 2004 17:55:37 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAbfq-0003Cb-CU for mip6@ietf.org; Thu, 23 Sep 2004 18:02:46 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2004 14:57:39 -0700
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8NLt3wr008737 for <mip6@ietf.org>; Thu, 23 Sep 2004 14:55:05 -0700 (PDT)
Received: from gdommety-w2k04.cisco.com (dhcp-128-107-178-184.cisco.com [128.107.178.184]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AEP89893; Thu, 23 Sep 2004 14:55:05 -0700 (PDT)
Message-Id: <4.3.2.7.2.20040923143829.029e1a48@mira-sjc5-d.cisco.com>
X-Sender: gdommety@mira-sjc5-d.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Sep 2004 14:55:05 -0700
To: mip6@ietf.org
From: Gopal Dommety <gdommety@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Subject: [Mip6] Summary of Justification for Alternative Authentication Option
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793

Hello All,

             I am attaching a summary of the discussion that took place on
justification of an alternate authentication mechanism.  Please let me know if
I have left out any important issue in the summary. I could have also mis-read
people opinions, so if there is a correction please let me know. I will 
send a follow-up
  email with the next steps.


Thanks,
-Gopal


Summary
=======

The WG has been engaged in a discussion over the last week on the
topic of standardizing an authentication date suboption based
mechanism for the purpose of registering an MN with its HA via the
BU/BAck messages.
To summarize the discussion in brief:
1. The I-D draft-patil-mip6-whyauthdataoption-00.txt was used as the
    baseline for the discussion
2. Opinion was expressed that the I-D was more inclined in justifying
    why the use of  IKE was a problem for setting up the MN-HA IPsec SA
    and not really providing sufficient justifications for an
    alternative scheme to the use of IPsec for securing the signaling
    messages between the MN and HA
3. There were a few people who expressed strong views of keeping IPsec
    as the only means for MIP6 security between MN and HA (Francis and 
Hesham (?))
4. There were others who claimed the need for an alternate option to
    MIP6 including one operator who plans to deploy the protocol in
    their network (Raj, James Kempf, Alpesh, Gopal, Kuntal, Vijay, Michael Roe)
5. There was also a note from an implementers perspective on the
    challenges of integrating MIP6 with IPsec (Michael Roe)
6. There was discussion about the problem of replay attacks and the
    need for key refreshment
7. IKEv2 is expected to provide a solution to the problem of setting
    up dynamic SAs in networks that rely on AAA infrastructures. While
    IKEv2 itself has been approved, the details of how IKEv2 is used
    with MIP6 are still being worked out in an I-D that is not ready
    yet.
8. There was an opinion that the bootstrap work being done in the WG
    would address the needs of the environment claimed in I-D
    draft-patil-mip6-whyauthdataoption-00.txt


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6